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Requirements for GMPLS Applications of PCE 
Abstract 
The initial effort of the PCE (Path Computation Element) WG focused 
mainly on MPLS. As a next step, this document describes functional 
requirements for GMPLS applications of PCE. 
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The initial effort of the PCE (Path Computation Element) WG focused 
mainly on solving the path computation problem within a domain or 
As with MPLS, service 
providers (SPs) have also come up with requirements for path 
[RFC3945], such as those 


over different domains in MPLS networks. 


computation in GMPLS-controlled networks 
based on Wavelength Division Multiplexing 
Multiplexing (TDM), or Ethernet. 


(WDM), 


Time Division 


[RFC4655] and [RFC4657] discuss the framework and requirements for 
PCE on both packet MPLS networks and GMPLS-controlled networks. This 
document complements those RFCs by providing considerations of GMPLS 
applications in the intradomain and interdomain networking 
environments and indicating a set of requirements for the extended 


definition of PCE-related protocols. 
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Note that the requirements for interlayer and inter-area traffic 
engineering (TE) described in [RFC6457] and [RFC4927] are outside of 
the scope of this document. 


Constrained Shortest Path First (CSPF) computation within a domain or 
over domains for signaling GMPLS Label Switched Paths (LSPs) is 
usually more stringent than that of MPLS TE LSPs [RFC4216], because 
the additional constraints, e.g., interface switching capability, 
link encoding, link protection capability, Shared Risk Link Group 
(SRLG) [RFC4202], and so forth, need to be considered to establish 
GMPLS LSPs. The GMPLS signaling protocol [RFC3473] is designed 
taking into account bidirectionality, switching type, encoding type, 
and protection attributes of the TE links spanned by the path, as 
well as LSP encoding and switching type of the endpoints, 
appropriately. 


This document provides requirements for GMPLS applications of PCE in 
support of GMPLS path computation, included are requirements for both 


intradomain and interdomain environments. 


GMPLS Applications of PCE 


.1. Path Computation in GMPLS Networks 


Figure 1 depicts a model GMPLS network, consisting of an ingress 
link, a transit link, as well as an egress link. We will use this 
model to investigate consistent guidelines for GMPLS path 
computation. Each link at each interface has its own switching 
capability, encoding type, and bandwidth. 


Ingress Transit Egress 
Tons + link1-2 panni + link2-3 pantsa + link3-4 G ie + 
|Node1 | ------------ > |Node2 | ------------ > |Node3 | ------------ » |Node4 | 
[<------------ | [<-=---------- | [<-=---------- pre 
q-———— + link2-1 FSS + link3-2 basa + link4-3 pu——- t 


Figure 1: Path Computation in GMPLS Networks 


For the simplicity in consideration, the following basic assumptions 
are made when the LSP is created. 


(1) Switching capabilities of outgoing links from the ingress and 
egress nodes (link1-2 and link4-3 in Figure 1) are consistent 
with each other. 


(2) Switching capabilities of all transit links, including incoming 
links to the ingress and egress nodes (link2-1 and link3-4) are 
consistent with switching type of an LSP to be created. 
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(3) Encoding types of all transit links are consistent with the 
encoding type of an LSP to be created. 


GMPLS-controlled networks (e.g., GMPLS-based TDM networks) are 
usually responsible for transmitting data for the client layer. 
These GMPLS-controlled networks can provide different types of 
connections for customer services based on different service 
bandwidth requests. 


The applications and the corresponding additional requirements for 
applying PCE to GMPLS-based TDM networks are described in this 


section. In order to simplify the description, this document only 
discusses the scenario in Synchronous Digital Hierarchy (SDH) 
networks as an example (see Figure 2). The scenarios in Synchronous 


Optical Network (SONET) or Optical Transport Network (OTN) are 
similar. 


N1 N2 
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------- bo qe | — 
— |o do | | | 
A1 4------ + 4------ + | | 
| | — + 
| | | PCE 
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| tease * | 
| | | | 
| Xn 
4£------ + 
| NS | | 
| | | 
4£------ + 4£------ + 
DEM l| — 
MES MEE | | 
4£------ + 4£------ + 4£----- + 
N3 N4 A2 


Figure 2: A Simple TDM (SDH) Network 


Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3, 
N4, and N5 are all SDH switches; Al and A2 are client devices (e.g., 
Ethernet switches). Assume that one Ethernet service with 100 Mbit/s 
bandwidth is required from A1 to A2 over this network. The client 
Ethernet service could be provided by a Virtual Container 4 (VC-4) 
container from N1 to N4; it could also be provided by three 


concatenated VC-3s (contiguous or virtual concatenation) from N1 to 
N4. 
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In this scenario, when the ingress node (e.g., N1) receives a client 
Service transmitting request, the type of containers (one VC-4 or 
three concatenated VC-3s) could be determined by the PCC (Path 
Computation Client), e.g., N1 or Network Management System (NMS). 
However, it could also be determined automatically by the PCE based 
on policy [RFC5394]. If it is determined by the PCC, then the PCC 
should be capable of specifying the ingress node and egress node, 
signal type, the type of the concatenation, and the number of the 
concatenation in a PCReq (Path Computation Request) message. The PCE 
should consider those parameters during path computation. The route 
information (co-routing or diverse routing) should be specified in a 
PCRep (Path Computation Reply) message if path computation is 
performed successfully. 


As described above, the PCC should be capable of specifying TE 
attributes defined in the next section, and the PCE should compute a 
path accordingly. 


Where a GMPLS network consists of interdomain (e.g., inter-AS or 
inter-area) GMPLS-controlled networks, requirements on the path 
computation follow [RFC5376] and [RFC4726]. 


2.2. Unnumbered Interface 


GMPLS supports unnumbered interface IDs as defined in [RFC3477]; this 
means that the endpoints of the path may be unnumbered. It should 
also be possible to request a path consisting of the mixture of 
numbered links and unnumbered links, or a P2MP (Point-to-Multipoint) 
path with different types of endpoints. Therefore, the PCC should be 
capable of indicating the unnumbered interface ID of the endpoints in 
the PCReq message. 


2.3. Asymmetric Bandwidth Path Computation 


Per [RFC6387], GMPLS signaling can be used for setting up an 
asymmetric bandwidth bidirectional LSP. If a PCE is responsible for 
path computation, it should be capable of computing a path for the 
bidirectional LSP with asymmetric bandwidth. This means that the PCC 
should be able to indicate the asymmetric bandwidth requirements in 
forward and reverse directions in the PCReq message. 
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3. Requirements for GMPLS Applications of PCE 
3.1. Requirements on Path Computation Request 


As for path computation in GMPLS-controlled networks as discussed in 
Section 2, the PCE should appropriately consider the GMPLS TE 
attributes listed below once a PCC or another PCE requests a path 
computation. The path calculation request message from the PCC or 
the PCE must contain the information specifying appropriate 
attributes. According to [RFC5440], [PCE-WSON-REQ], and RSVP 
procedures such as explicit label control (ELC), the additional 
attributes introduced are as follows: 


(1) Switching capability/type: as defined in [RFC3471], [RFC4203], 
and all current and future values. 


(2) Encoding type: as defined in [RFC3471], [RFC4203], and all 
current and future values. 


(3) Signal type: as defined in [RFC4606] and all current and future 
values. 
(4) Concatenation type: In SDH/SONET and OTN, two kinds of 


concatenation modes are defined: contiguous concatenation, 
which requires co-routing for each member signal and that all 
the interfaces along the path support this capability, and 
virtual concatenation, which allows diverse routing for member 
Signals and requires that only the ingress and egress 
interfaces support this capability. Note that for the virtual 
concatenation, it may also specify co-routing or diverse 
routing. See [RFC4606] and [RFC4328] about concatenation 
information. 


(5) Concatenation number: Indicates the number of signals that are 
requested to be contiguously or virtually concatenated. Also 
see [RFC4606] and [RFC4328]. 


(6) Technology-specific label(s): as defined in [RFC4606], 
[RFC6060], [RFC6002], or [RFC6205]. 


(7) End-to-End (E2E) path protection type: as defined in [RFC4872], 
e.g., 1+1 protection, 1:1 protection, (pre-planned) rerouting, 
etc. 

(8) Administrative group: as defined in [RFC3630]. 

(9) Link protection type: as defined in [RFC4203]. 
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(10) Support for unnumbered interfaces: as defined in [RFC3477]. 
(11) Support for asymmetric bandwidth requests: as defined in 
[RFC6387]. 


(12) Support for explicit label control during the path computation. 


(13) Support of label restrictions in the requests/responses, 
similar to RSVP-TE ERO (Explicit Route Object) and XRO (Exclude 
Route Object), as defined in [RFC3473] and [RFC4874]. 


3.2. Requirements on Path Computation Reply 


As described above, a PCE should compute the path that satisfies the 
constraints specified in the PCReq message. Then, the PCE should 
send a PCRep message, including the computation result, to the PCC. 
For a Path Computation Reply message (PCRep) in GMPLS networks, there 


are some additional requirements. The PCEP (PCE communication 
protocol) PCRep message must be extended to meet the following 
requirements. 

(1) Path computation with concatenation 


In the case of path computation involving concatenation, when a 
PCE receives the PCReq message specifying the concatenation 
constraints described in Section 3.1, the PCE should compute a 
path accordingly. 


For path computation involving contiguous concatenation, a 
single route is required, and all the interfaces along the route 
should support contiguous concatenation capability. Therefore, 
the PCE should compute a path based on the contiguous 
concatenation capability of each interface and only one ERO that 
should carry the route information for the response. 


For path computation involving virtual concatenation, only the 
ingress/egress interfaces need to support virtual concatenation 
capability, and there may be diverse routes for the different 
member signals. Therefore, multiple EROs may be needed for the 
response. Each ERO may represent the route of one or multiple 
member signals. When one ERO represents multiple member 
signals, the number must be specified. 
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(2) Label constraint 


In the case that a PCC does not specify the exact label(s) when 
requesting a label-restricted path and the PCE is capable of 
performing the route computation and label assignment 
computation procedure, the PCE needs to be able to specify the 
label of the path in a PCRep message. 


Wavelength restriction is a typical case of label restriction. 
More generally, label switching and selection constraints may 
apply in GMPLS-controlled networks, and a PCC may request a PCE 
to take label constraint into account and return an ERO 
containing the label or set of labels that fulfill the PCC 
request. 


(3) Roles of the routes 


When a PCC specifies the protection type of an LSP, the PCE 
should compute the working route and the corresponding 
protection route(s). Therefore, the PCRep should allow to 
distinguish the working (nominal) and the protection routes. 
According to these routes, the RSVP-TE procedure appropriately 
creates both the working and the protection LSPs, for example, 
with the ASSOCIATION object [RFC6689]. 


3.3.  GMPLS PCE Management 


This document does not change any of the management or operational 
details for networks that utilize PCE. (Please refer to [RFC4655] 
for manageability considerations for a PCE-based architecture.) 
However, this document proposes the introduction of several PCEP 
objects and data for the better integration of PCE with GMPLS 
networks. Those protocol elements will need to be visible in any 
management tools that apply to the PCE, PCC, and PCEP. That 
includes, but is not limited to, adding appropriate objects to 
existing PCE MIB modules that are used for modeling and monitoring 


PCEP deployments [PCEP-MIB]. Ideas for what objects are needed may 
be guided by the relevant GMPLS extensions in GMPLS-TE-STD-MIB 
[RFC4802]. 

4. Security Considerations 


PCEP extensions to support GMPLS should be considered under the same 
security as current PCE work, and this extension will not change the 
underlying security issues. Section 10 of [RFC5440] describes the 
list of security considerations in PCEP. At the time [RFC5440] was 
published, TCP Authentication Option (TCP-AO) had not been fully 
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6. 


6. 


Specified for securing the TCP connections that underlie PCEP 
sessions.  TCP-AO [RFC5925] has now been published, and PCEP 
implementations should fully support TCP-AO according to [RFC6952]. 
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